红队视角下的公有云基础组件安全（二）
编者注：本文仅供学习研究，严禁从事非法活动，任何后果由使用者本人负责。
前言
在去年年底，我们已经发过一篇红队视角下的公有云基础组件安全的文章，这篇是对上一篇内容的补充，主要为国外公有云如AWS、Google Cloud、Azure。
本文主要从红队视角讲述公有云基本服务中一些因配置问题产生的安全风险。
目录
● 云存储
● 云计算
● 云网络
● 其他
云存储
Azure Storage
Azure Storage 是微软云出品的文件存储功能，他有一个重要的概念，那就是储存账户。
首先我们需要明确一下Azure Storage的一个重要概念。
储存账户（Azure Storage Account） ：Azure 存储帐户包含所有 Azure 存储数据对象，其中包括 Blob、文件共享、队列、表和磁盘。存储帐户为 Azure 存储数据提供一个唯一的命名空间，可通过 HTTP 或 HTTPS 从世界上的任何位置访问该数据。
可以这样去理解，所有的储存服务，都是在一个储存账户下的。
按照储存账户的结构分为以下几部分，分别是 Containers 、 File Share 、Queues、 Tables、VM Disk，储存账户提供以下三种鉴权办法：
1. Access Keys(AK)
2. Azure Active Directory(AAD)
3. Share access signature(SAS)
当账户开启 Allow storage account key access的时候，储存账户开放外部访问。
观察一下各个部分的鉴权，可以发现容器、队列以及表使用AAD与SAS进行鉴权，而文件共享是采用AK与AAD进行鉴权，并且AK对是完全继承于储存账户的。
当我们拿着AK去Azure专门的文件浏览器当中进行登陆，我们能获得的不止是单一的共享文件夹，而是接管了整个储存账户。
当我们在一台利用Azure AK脚本挂载过文件共享账户的Windows机器上利用mimikatz进行内存密码抓取时，可以发现账户的明文AK是储存在内存当中的，这也导致如果利用AK挂载过文件共享的机器一旦失陷，你的整个存储账户都会处于风险当中。
由于Azure对于文件共享并没有细小的权限划分，所以使用文件共享需要多加谨慎，经过测试，在使用AAD进行鉴权的时候，由于全程无明文密码输入，内存当中不会存在相关痕迹，在机器失陷的恶劣情况下，会尽可能的保护存储账户。
Azure Storage的AK是存在过期时间的，不要设置成永久不过期；注意开发安全，关于带有文件共享AK的代码不要上传互联网，并且注意项目公开权限；云上的机器尽可能的采用AAD认证，由于本地机器是无法加入AAD的，建议本地机器不要使用文件共享功能。
Amazon S3
静态网站导致子域名接管
aws的s3官方提供了托管静态网站的功能，虽然国内的云厂商的存储也可以拿来托管静态网站，但是和aws的还是有区别的，因为aws存在可以通过注册接管对方的子域名的可能。
通过在存储桶的界面属性中可以开启对应的静态网站功能。
成功开启后aws会分配一个存储桶的网站终端节点。
如果存在之前托管的静态网站的存储桶已经删除，但是自定义域名的解析还没有及时处理的话，当访问目标子域名会显示存储桶不存在的提示NoSuchBucket，我们就可以通过注册唯一桶名为该子域名的名称注册一个桶接管。
特定策略泄漏
s3针对一些访问的特殊需要等等可以通过设置存储桶策略达到通过某特定的请求头等达到针对性访问的效果。
如下官网示范的通过请求中具有x-amz-full-control标头，授予存储桶拥有者完全控制权限。
还有通过一些范围的条件键达到访问控制的效果，如下图中的ip为范围内的通过验证即可以访问，除非188的ip：
{ "Version": "2012-10-17", "Id": "S3PolicyId1", "Statement": [ { "Sid": "statement1", "Effect": "Allow", "Principal": "*", "Action":"s3:GetObject", "Resource": "arn:aws:s3:::awsexamplebucket1/*", "Condition" : { "IpAddress" : { "aws:SourceIp": "192.0.2.0/24" }, "NotIpAddress" : { "aws:SourceIp": "192.0.2.188/32" } } } ]}通过测试这些可能存在的策略，如果目标设置的较为简单可以通过测试达到绕过目标的策略限制。
云计算
云容器
厂商有些目前会提供基于云的云实例，比如云容器实例CCI等。
云容器利用
可以借助这个功能，自己构建需要的一些功能性的镜像，这里举例构建一个awvs的web扫描，搭配云厂商提供的负载均衡等功能，达到容器的性能需求。
云容器指令泄漏
云容器厂商一般会提供一些公共的镜像，但是涉及到自己构建镜像时，需要将构建完成的镜像进行上传，厂商会提供临时指令和永久指令。
其中永久指令的登录是通过ak作为用户名，密钥是通过ak和sk加密得到的一个密钥，这个密钥是不可被解密的，这里需要注意加密密钥的泄漏。
ECR公开访问
Amazon Elastic Container Registry (Amazon ECR) 是 AWS 托管容器映像注册表服务，它安全、可扩展且可靠。Amazon ECR 支持私有存储库，其具有使用 AWS IAM 的基于资源的权限。这样，指定用户或 Amazon EC2 实例可以访问您的容器存储库和映像。您可以使用首选 CLI 推送、提取和管理 Docker 映像、Open Container Itistry (OCI) 映像和 OCI 兼容构件。
并且在官网中明确表明ECR支持作为公共容器映像存储库，所以在注册时可以看到公有的选项，一但打开就不可关闭，并且任意aws账户可以在这个容器存储库中随意推送和拉取。
云网络
DNS zone
照比国内厂商，国外厂商对DNS的管控有极高的自由度，在国内厂商，当无法验证你的根域名解析到相应平台的时候，是不会对你的域名进行任何解析的，这一点也是很好的保护了我国公民的网络安全，而国外的云厂商是不会对你的域名进行Name Server的验证的，所以，你可以在境外平台例如Azure、Google、AWS等等去解析不属于你的域名。
以Azure为例，执行以下操作就可以解析他人的域名。
创建 DNS zone。
选择一个你想要的域名。
添加记录，跟操作国内的DNS一样。
最终效果：
通过平台给出的四个NS节点去解析，会得到自己配置的地址，如图，ns1-38是强制加的记录，而ns1-205则是真实的microsoft.cn记录，这种方式可以在恶意程序中指定DNS服务器，将自己想要的地址通过指定的服务器进行查询，这样做有以下两个特点：
● 域名高度伪装，可以想象一下，在一个月黑风高的夜里，态势感知、流量设备发出了告警，但是告警的内容是向[www.microsoft.cn] 或者向自己驻守单位的主域名发起连接，我猜，你的脑子里会一片空白。
● 解析的DNS服务器是一个比较权威的服务器，并不是个人搭的野鸡服务器，以mincrosoft.cn为例，真实的DNS解析记录在ns1-205上而我注册的是在ns1-38上，都是情报上白名单的权威服务器，在域名的记录里加一个微软云的ip或者CDN，很容易让防守人员产生误判，认为是微软服务发起的连接。
针对这一类攻击手法，如果防守方人员在看到这种连接，在沙箱当中跑出来没什么问题，请一定在虚拟机当中跑起来抓包，看发出的DNS服务器是指向哪台DNS，由于根域名的NS没有指向假冒的DNS服务器，解析记录是不会在互联网上进行传播的，通过比对Name Server来找出样本的猫腻。
AWS DNS Zone
Google Cloud DNS Zone
由于Google的DNS服务器国内是无法访问的，因为这一点，身处国内的服务器可以不用考虑这个安全风险。
NAT网关
NAT网关（NAT Gateway）提供公网NAT网关和私网NAT网关。公网NAT网关为VPC内的云主机提供SNAT和DNAT功能，可轻松构建VPC的公网出入口。私网NAT网关为VPC内的云主机提供网络地址转换服务，使多个云主机可以共享私网IP访问用户本地数据中心或其他VPC，并支持云主机面向私网提供服务。
● SNAT
某厂商的本意是通过NAT网关提供网络地址转换服务，使用NAT网关节约EIP资源，通过NAT网关还可以实现VPC内云主机与远端私网（外部数据中心或其他VPC）互相访问。
在红队视角下我们可以通过云主机搭配弹性公网IP结合SNAT的策略避免IP直接暴露在公网上，可以通过公网NAT网关共享弹性公网IP的方式访问公网，实现VPC内的无弹性公网IP的云主机访问公网。
首先我们根据自己的需要购买网关。
购买完成确定后，进入到网关的规则设置内设置SNAT规则。
根据需要购买EIP之后，在下面会显示购买的IP，由于弹性云服务器同时配置弹性公网IP服务和NAT网关服务时，数据均通过弹性公网IP转发，所以我们需要将之前购买的服务器送的ip进行解绑，并且在解绑后送的ip也可以拿到网关中使用。
以上设置完成后我们的服务器就有了自动出网切换ip的能力。
可以看到我们的ip，自动进行了切换，我们可以通过这个手法达到隐藏自己的真实ip并切换的能力，同时获得了国内的高质量代理。
● DNAT
DNAT的功能恰好与SNAT相反，通过IP映射或端口映射的方式，实现VPC内的机器被外网访问，在之前的操作中，我们将机器本身的ip解绑，我们只能通过网页的远程VNC登录系统操作，这样极其不方便，首先我们可以通过这个方法将我们的22端口映射出去，方便我们操作机器。
之前相关的资源已经购买，直接去设置DNAT规则就可以。
根据需要设置规则，我这里只将22放了出来。
成功使用ssh，其他利用比如隐藏CS、监听器的设置等等都可以利用。
其他
Azure Active Directory 所带来的密码爆破风险
在微软的体系下，Microsoft365、Azure以及其他的一些微软服务的登陆凭据都是互认的，暴力破解的过程中可以采用一些微软的公网服务接口进行账号验证，而这时就会产生一个问题，如何保证账户在公网上的安全性。现已知的非核心密码验证接口，有如下几个：
● Microsoft 365 Web Portal
● Microsoft Graph
● Azure Service Management
● Microsoft 365 Mobile
这些存在的接口都会导致一个问题，那就是攻击者可以在域外、公网上进行域用户的暴力破解，因为真实的流量不会在云内网或者主机上发出，所以任何的安全设备也不会对它进行告警。为了避免这种情况的产生，可以采用以下方法进行规避：
● 为所有用户开启多因子MFA认证
● 使用“读取目录数据”或“读取用户配置文件”权限监控和阻止可疑应用程序
● 使用白名单控制登陆ip地址
CloudShell
AWS CloudShell是一个基于浏览器的预先验证 shell，可以直接启动来自 的AWS Management Console. 可以使用的首选 shell（Bash、PowerShell 或 Z shell），针对 AWS 服务运行 AWS CLI 命令。无需下载或安装命令行工具，即可完成此操作。
在控制左上方可以进入CloudShell，点击进入会初始化生存，每次进入都是根据区域随机ip。
该shell默认提供bash、powershell、zsh3种，并且aws相关的cli都提供，开发环境提供node.js、python。
默认用户是低权限的，但是官方为了用户安装软件给了当前用户sudo的权限。
可以看到用户属于sudo组，这样我们就能干很多事。
shell的配置资源如下，可以用来做一些事情了。
此外，在近期发布的3.0版本中，默安科技巡哨智能资产风险监控系统正式引入云安全状态管理（CSPM，Cloud Security Posture Management）能力，帮助用户实现多云资源的统一管理、云资产可视、云资源配置风险的及时发现；通过云上合规基线检查，让用户能够轻松应对云上合规困扰；并且同时支持私有化交付与SaaS化交付。
参考内容
https://attack.mitre.org/matrices/enterprise/cloud/iaas/
https://docs.aws.amazon.com/zh_cn/index.html
https://support.huaweicloud.com/intl/zh-cn/index.html
https://docs.microsoft.com/zh-cn/azure/storage/common/storage-account-overview?toc=/azure/storage/blobs/toc.json
https://github.com/dafthack/MFASweep
https://danielchronlund.com/2020/03/17/azure-ad-password-spray-attacks-with-powershell-and-how-to-defend-your-tenant/
默安科技安全研究院旗下团队，“逐日”寓意为追逐技术永不停歇，专注于安全攻防研究，包括漏洞挖掘、逆向工程、红蓝对抗、代码审计、产品赋能等方向。